Hardware Security Module (HSM): What is it and what is it for?

One of the main problems arising from the use of cryptography for the protection of sensitive data during its storage and transmission is complexity in lifecycle management of encryption keys (generation, storage, import/export, distribution, rotation, replacement, backup, revocation, suspension, destruction, audit, etc.). Because the security of the cryptographic system must fall on the security of the key (Kerckhoffs Principle), this key must be managed in the most secure way possible, since it is assumed that the potential attacker can know or have access to the rest of the parameters of the cryptographic system (algorithm used, encrypted text, clear text). If the key is compromised, the entire cryptographic system is compromised ("A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.).

Cryptographic key life cycle. Source: NIST Special Publication 800-57 Part 1

In this sense, one of the most recommended alternatives to perform the management of cryptographic keys is through the use of a Hardware Security Module (Hardware Security Module – HSM). An HSM (also known as Secure Application Module (SAM), Secure Cryptographic Device (SCD), Cryptographic Device Hardware (HCD) or simply Cryptographic Module) is a secure and tamper-resistant cryptoprocessor (tamper-resistant) specifically designed to protect the life cycle of cryptographic keys and execute encryption and decryption routines, providing a high level of security in terms of confidentiality, integrity and availability of cryptographic keys and any sensitive data processed.

Internal architecture of an HSM. Source: IBM 4770-001

HSMs can be found on smart cards (smart cards), portable devices, dedicated cards (cryptographic cards), self-contained devices (appliances) or offered as a cloud service (HSM-as-a-Service).

Different types of HSM: Cryptographic card, appliance, HSM USB (nano) and smart card

Operation of HSMs

HSMs are security devices that manage the lifecycle of cryptographic keys and run encryption and data decryption routines. In that sense, its operation can be broken down as follows:

• • Physically, the device must operate in a safe environment.
  • It has a communication channel with the outside for the reception of data to be encrypted or decrypted. These channels are usually authenticated and restricted only for access by authorized elements. They can be local or remote channels.
  • The HSM stores a master key in its protected memory (Master Key) which receives different names depending on the manufacturer (Local Master Key (LMK), Master File Key (MFK), etc.). This key is responsible for protecting all other cryptographic keys under its hierarchy and cannot be exported in clear outside the device. Any attempt to gain unauthorized access (either physically or logically) to the master key can trigger HSM protection routines (anti-tampering).
  • Depending on the manufacturer, operational keys – once encrypted with the master key – can be exported externally to the device to be stored in files or databases. These encrypted keys are named after cryptograms.
  • Likewise, the HSM can be managed remotely or by console.
  • These devices can operate at different levels of security, depending on the activities to be performed:
    • Unauthenticated mode: Allows obtaining non-sensitive information from the device (CPU usage, memory, network configuration information, etc.)
    • Authenticated mode: It allows the execution of sensitive tasks, such as the creation, upload or export of keys, secure deletion of the device, creation of users, etc. In this chaos, dual authentication may be required (two users must be authenticated correctly) before proceeding.
  • For its operation, it is usually allowed to create different users or roles that must be previously authenticated in order to execute tasks on the device.

Operation of an HSM

Types of HSM

Depending on the needs, HSM devices can be categorized into two types:

• General Purpose HSM (General Purpose HSM): HSM devices that include a variety of standard encryption algorithms (symmetric, asymmetric and hash functions) with support for interconnectivity via API using Public-Key Cryptography Standard (PKCS) #11, Microsoft Cryptographic Application Programming Interface (CAPI), Cryptography API Next Generation (CNG), Java Cryptography Architecture (JCA), Java Cryptography Extension (JCE) and others. These devices are typically used in PKI environments, HTTPS channels, DNSSEC, generic sensitive data protection, and cryptocurrency wallets, among others.
• HSM transactional and for payments (Transaction and Payment HSM): Specific HSM devices for the protection of payment transactions that include the use of pin (generation, management, validation and transfer of PIN Block (PIN Block) in transactions carried out in POS and ATMs), the protection of electronic funds transfers (EFT), the generation of data for magnetic stripes y EMV Chips in card production and customisation processes, the processing of payment transactions with debit and credit cards and the validation of cards, users and cryptograms. These devices typically provide cryptographic support for the payment applications of most card brands and their interconnection interfaces are typically more limited than generic HSMs.

Validation of security levels of HSM devices

In order to validate the security levels of this type of devices, a series of international standards have been defined within which they are:

• FIPS (Federal Information Processing Standard) 140-2 y 140-3 (Security Requirements for Cryptographic Modules): It is a standard aimed at validating the effectiveness of cryptographic hardware. Despite being a U.S. and Canadian federal standard, it is recognized globally in both the government and private sectors. This certification defines four levels of safety, from the lowest (Level 1) to the most restrictive (Level 4):
  • Level 1: It includes basic security requirements (at least one algorithm or an approved function must be used), allowing the software and firmware components of the cryptographic module to be executed on a general purpose system using an unevaluated operating system. Physical security mechanisms are not included. Example: encryption card of a personal computer.
  • Level 2: This level improves the security of Level 1 by requiring the use of mechanisms for the detection of unauthorized manipulation (tamper-evidence) and role-based authentication. Software implementations must run on an operating system approved as EAL2 of Common Criteria.
  • Level 3:  This level requires additional requirements to withstand unauthorized tampering (tamper-resistance), response to such manipulations (deletion of security parameters) and identity-based authentication. Likewise, a logical separation between interfaces by which critical security parameters enter and exit the system is required. Private keys can only be imported or exported in encrypted form.
  • Level 4: The latter level includes advanced intrusion protection (tamper-active) and is designed for products operating in physically unprotected environments.
• Common Criteria (ISO/IEC 15408): Common Criteria for Information Technology Security Evaluation is an internationally recognized certification standard for the security of IT products and systems. It was developed by Canada, France, Germany, the Netherlands, the UK and the US in the 1990s. Products evaluated under Common Criteria are categorized into levels (Evaluation Assurance Level – EAL), with EAL1 being the lowest and EAL 7 the strictest.
• Payment Card Industry (PCI) PTS HSM Security Requirements (PCI HSM): The PCI HSM standard is part of the PCI SSC PIN Transaction Security (PTS) standards group and defines the necessary security controls during the manufacturing, shipping, use and dismantling processes of HSM devices used in financial transactions.

In addition, some countries have developed specific regulations for the management of keys and algorithms in HSM devices that may require special certifications, such as Germany (DK), France (CB MEPS), Australia (APCA CECS) or Italy.

HSM devices and their relationship to PCI SSC standards

Cryptography is one of the basic mechanisms used for the protection of transactional data related to payment cards. As a result, many of the controls of the PCI SSC standards (PCI DSS, PCI PIN, PCI P2PE, PCI 3DS, PCI Card Production, etc.) require formal management of cryptographic keys and – in some cases – require the use of specific and certified HSMs.

Listed below are some of the PCI SSC standards and their requirements in terms of using HSM devices:

Likewise, the certifications of these devices usually have a period of validity, in order to manage their life cycle. Depending on the program and/or standard, the use of expired devices is usually restricted.

Validation and expiration dates for these devices can be found at the following links:

PCI HSM devices: https://listings.pcisecuritystandards.org/assessors_and_solutions/pin_transaction_devices?agree=true

FIPS Devices (NIST Cryptographic Module Validation Program): https://csrc.nist.gov/Projects/cryptographic-module-validation-program/validated-modules/search

Additional controls for HSM protection in PCI environments

Under certain scenarios, some devices (usually PCI HSM certified devices) require additional physical controls in restricted environments (restricted environments) to mitigate issues that are not managed through their native controls. In these cases, it is very important to validate both with the seller of the solution and in the listings the need for these controls. Usually, the controls required for these restricted environments align with the standard ISO 13491-2:2023 Financial services — Secure cryptographic devices (retail)Part 2: Security compliance checklists for devices used in financial transactions, These have to be validated in addition to the own controls of both the HSM and the standard applicable to the operation of the device.

Thales 10K device entry on the PCI SSC site. Please note the field “Additional Information”

Additional information from the PCI HSM validation stating that the device must be deployed in a restricted environment (ISO 13491-2)

PCI HSM security policy indicating the use of a restricted environment

Remote management on HSM devices

For years, one of the main problems of HSM devices (mainly those in format appliance) was the absence of secure interfaces for its administration, operation and management of cryptographic keys. Traditionally, generic terminals were used (type VT-100) or multipurpose computers, which added a risk point in the process, since it was possible that sensitive material was transmitted and / or stored in the used terminals. These terminals used to connect via serial, parallel, USB or even exclusive ethernet ports. This task used to be quite cumbersome, as it required physical access to the HSM (which was usually located in a data center), as well as the interaction of different people/roles to ensure dual control.

Multipurpose terminal connected to an HSM

With PCI HSM v3 input, the use of remote management of HSM devices is allowed. In this case, instead of using a local connection to the device, a remote connection (usually ethernet) is used between the device and a secure central location where the console is located. As can be inferred, the goal is to prevent physical travel to data centers, secure data transmission channels, and prevent uncontrolled storage of sensitive data on insecure devices and is widely used in cloud HSM environments.

This functionality can be provided by the device itself (as part of its PCI HSM certification) or through an external device called Remote Administration Platform (RAP):

Remote management functionality in Thales 10K

Certification as Remote Administration Platform (RAP)

Details of the implementation and additional security controls for remote management can be found in the manufacturer's documentation, in the security standards (mainly PCI HSM) or in the technical frequently used questions (Technical FAQs), mainly from PCI PIN and P2PE.

HSM cloud and HSM-as-a-Service (HSMaaS) services

In addition to the HSM model deployed locally in the organization (on-premises), many cloud service providers and HSM device manufacturers are offering cloud services. Hardware Security Module "as a Service" or managed. This new model offers many advantages over the traditional model, including high scalability, availability and additional integration options. Some examples of these services are:

• Microsoft Azure: Azure Dedicated HSM y Azure Key Vault
• Google Cloud Platform: Cloud HSM y Cloud Key Management Service
• Amazon Web Services: AWS Key Management Service (KMS), AWS CloudHSM y AWS Payment Cryptography (service validated in PCI PIN and P2PE)
• IBM Cloud Hardware Security Module
• Utimaco HSM-as-a-Service (service validated in PCI PIN and P2PE)
• nCipher nShield-as-a-Service
• Thales CipherTrust Cloud Key Manager

However, it is important to note that using these managed or cloud services offers general purpose HSM devices that may be useful for integration with PCI DSS environments but not for use in PCI PIN, PCI P2PE or PCI 3DS environments, as these standards require transactional HSMs with special cryptographic support and additional physical and device lifecycle security controls. In that sense, before hiring this type of services it is very important that the entity validates whether there are compliance requirements (such as PCI PIN, P2PE, etc.) and the type of functionalities required by the operation.

Flowchart for selecting an HSM service in the cloud. Source: Microsoft

Conclusion

Bruce Schneier, in his book Applied Cryptography It said: Cryptographic key management is the most difficult part of cryptography and often the Achilles heel of a secure system. A safe and not so complicated way to perform this management is using hardware security modules (HSM). These devices allow secure key management, secure processing of sensitive data and comply with strict certifiable security requirements and are a secure alternative to the use of generic cryptographic software libraries, adding layers of physical and logical protection that allow the protection of cryptographic processes.